Refer to the ASR 5000 Installation Guide for comprehensive descriptions of the hardware components addressed by these troubleshooting procedures.
Important: As the system progresses through its boot process, some cards will not exhibit immediate LED activity. Allow several minutes to elapse after a reboot is initiates before checking the LEDs on the various cards to verify that the boot process has successfully completed.The status of application and line card LEDs can be viewed through the CLI by entering the show leds all command in Exec mode.
The status of the two Power Filter Units (PFUs) can be viewed by entering the show power chassis command in the Exec mode.
|
•
|
|
•
|
|
•
|
|
•
|
|
•
|
|
•
|
The SMC Run/Fail LED indicates the overall status of the card. This LED should be green for normal operation.
|
||||||||
|
The Active LED on the SMC indicates that the software is loaded on the card and it is ready for operation. For the SMC installed in chassis slot 8, this LED should be green for normal operation. For the SMC installed in slot 9, this LED should be off for normal operation.
|
Verify that the Standby LED on the redundant SMC is also blinking green. If so, there is an issue with the active SMC. Refer to one or more of the following to help analyze this problem:
|
||||||||
|
Card is not receiving power. OR Card is in Standby Mode.
|
|
The Standby LED on the SMC indicates that software is loaded on the card, but it is serving as a redundant component. For the SMC installed in slot 9, this LED should be green for normal operation. For the SMC installed in slot 8, this LED should be off for normal operation.
|
Verify that the Active LED on the redundant SMC is also blinking green. If so, there is an issue with the active SMC. Refer to one or more of the following to help analyze this problem:
|
||||||||
|
Card is not receiving power. OR Card is in Active Mode.
|
|
The Status LEDs on the SMC indicate the status of system level hardware such as installed cards, fans, and PFUs. This LED is green during normal operation.
|
||||||||||
|
Verify that the Run/Fail LED is green. If so, the card is receiving power and POST test results are positive. If it is off, refer to the SMC Run/Fail LED States section for troubleshooting information.
|
The Service LEDs on the SMCs indicate that the system requires maintenance or service (for example, the system could not locate a a valid software image at boot-up, or a high temperature condition exists).
|
||||||||
The Busy LEDs on the SMCs indicate that there is activity on one of their memory devices. Activity is displayed for the following memory devices:
|
NOTE: You should wait until this LED is off before removing the SMC from the chassis. This practice ensures the integrity of all data being transferred to or from the memory device.
|
||
The ASR 5000 supports a variety of packet processing cards (PSCn and PPC). For detailed information about the types of cards and their applications, refer to the ASR 5000 Installation Guide.
|
•
|
|
•
|
|
•
|
|
•
|
|
•
|
The packet processing card Run/Fail LED indicates the overall status of the card. This LED should be green for normal operation.
|
||||||||
|
The Active LED on a packet processing card indicates that the software is loaded on the card and that the card is ready for operation. When the system first boots up, all installed packet processing cards are booted into standby mode. The system must then be configured as to which packet processing cards should serve as redundant components (remain in standby mode) and which should function as active components.
|
Verify that the Standby LED on a redundant packet processing card is also blinking green. If so, there is an issue with the card that was active and is transferring its processes.
Refer to the Monitoring the System chapter of this guide for information on determining the status of the packet processing card and system software processes.
|
||||||
|
Card is not receiving power. OR Card is in Standby Mode.
|
|
The Standby LED on a packet processing card indicates that software is loaded on the card, but the card is serving as a redundant component. When the system first boots up, all installed packet processing cards are booted into standby mode. The system must then be configured as to which packet processing cards should be redundant (remain in standby mode) and which should be active.
|
Verify that the Active LED on the redundant packet processing card is also blinking green.
|
||||||||
|
|
•
|
|
•
|
|
•
|
|
•
|
|
•
|
The SPIO Run/Fail LED indicates the overall status of the card. This LED should be green for normal operation.
|
Refer to the Monitoring the System chapter of this guide for information on determining the status of system hardware components.
|
||||||
|
The Active LED on the SPIO indicates that the software is loaded on the card and that the card is ready for operation. For the SPIO installed in chassis slot 24, this LED should be green for normal operation. For the SPIO installed in slot 25, this LED should be off for normal operation.
|
Card is not receiving power. OR Card in Standby Mode.
|
|
The Standby LED on the SPIO indicates that software is loaded on the card, but it is serving as a redundant component. For the SPIO installed in slot 25, this LED should be green for normal operation. For the SPIO installed in slot 24, this LED should be off for normal operation.
|
||||||||
|
Card is not receiving power. OR Card is in Active Mode.
|
|
The Link LED, associated with a particular SPIO interface indicates the status of the network link. This LED should be green for normal operation.
|
NOTE: This LED will not indicate the presence of a network link until the interface parameters are set during the software configuration process.
|
||||
|
No power is available to card. OR Link is down.
|
|
The Activity LED associated with a particular SPIO interface indicates the presence of traffic on the network link. This LED should be green when data is being transmitted or received over the interface.
The ASR 5000 can be equipped with a variety of Ethernet line cards that support subscriber traffic. For detailed information about the types of line cards and their applications, refer to the ASR 5000 Installation Guide
|
•
|
|
•
|
|
•
|
In addition to the LEDs listed above, each network interface is equipped with the Link and Activity LEDs.
The Run/Fail LEDs on the Ethernet line cards indicate the overall status of the cards. These LEDs should be green for normal operation.
|
Refer to the Monitoring the System chapter of this guide for information on determining the status of system hardware components.
|
||||||
|
The Active LEDs on the Ethernet line cards indicate that the operating software is loaded on the card and that the card is ready for operation.
Important: QGLCs and XGLCs only work in an ASR 5000 behind specific types of packet processing cards. Refer to the ASR 5000 Installation Guide for details.The line cards will remain in a ready mode until their corresponding packet processing card is made active via configuration. While in ready mode the Active LED should be off. After the packet processing card is made active, the line card installed in the upper-rear chassis slot behind the packet processing card will also be made active. The line card (except for the Full-height XGLC) installed in the lower-rear chassis slot behind the packet processing card will enter the standby mode.
|
The Standby LEDs on the Ethernet line cards indicate that software is loaded on the cards, but are serving as redundant components.
|
If green for line cards installed in slots 17 through 23 and 26 through 32, refer to the Monitoring the System chapter of this guide for information on determining the status of the line card and system software processes.
|
||||||||
|
The Link LEDs, associated with a particular network interface on the Ethernet line cards, indicate the status of the network link. These LEDs should be green for normal operation.
|
NOTE: This LED will not indicate the presence of a network link until the interface parameters are set during the software configuration process.
|
||||
|
No power is available to the card. OR Link is down.
|
|
The Activity LEDs, associated with a particular network interface on the Ethernet line cards, indicate the presence of traffic on the network link. These LEDs should be green when data is being transmitted or received over the interface.
|
•
|
|
•
|
|
•
|
The Run/Fail LED indicates the overall status of the card. This LED should be green for normal operation.
|
Refer to the Monitoring the System chapter of this guide for information on determining the status of system hardware components.
|
||||||
|
The Active LED on the RCC indicates that the card is being used. For normal operation, this LED should be off on both RCCs.
|
Refer to the Checking the LEDs on the Packet Processing Cards section to determine which card has failed.
|
||||||
|
Card is not receiving power. OR Card is in Standby Mode.
|
|
The Standby LED on the RCC indicates that software is loaded on the card and is ready to provide a path for data or signalling traffic from a line card to a redundant packet processing card. This LED should be on for normal operation for both RCCs installed.
|
Card is not receiving power. OR Card is in Active Mode.
|
|
|
•
|
System Audible Alarm: Located on the SMC, the speaker is used to provide an audible indicator that a minor, major, or critical alarm has occurred.
|
|
•
|
CO Alarms Interface: Located on the SPIO, this interface provides a 10-pin connector that enables three dry-contact relays (Form C) for the triggering of external audio and/or visual indicators. These indicators can be used to alert that either a minor, major, or critical alarm has occurred.
|
|
[local]host_name#
|
Step 2
|
Press Y to start the switchover.
|
Check the entry in the Oper State column next to the SMC just switched. Its state should be Standby.
[local]host_name#
|
Specifies the chassis slot number of the packet processing card that is being migrated from original_slot which can be any value between 1 through 7, and 10 through 16.
|
|
|
Specifies the chassis slot number of the packet processing card that is being migrated to final_slot which can be any value between 1 through 7, and 10 through 16.
|
|
Step 2
|
Press Y to start the migration.
|
Check the entry in the Oper State column next to the packet processing card that was just migrated from. Its state should be Standby. The state of the packet processing card migrated to should be Active.
[local]host_name#
|
Step 2
|
Press Y to start the switch.
|
Check the entry in the Oper State column next to the line card or SPIO that was just switched from. Its state should be Standby. The state of the line card or SPIO switched to should be Active.
[local]host_name#
card halt <slot#>
slot# is the chassis slot number in which the card to be halted is installed. It can be any integer value between 1 and 7, 10 through 48. You will receive the following prompt:
|
Step 2
|
Press Y to initiate the halt operation.
|
Check the entry in the Oper State column next to the line card that was just halted. Its state should be Offline. If the card was in active mode prior to the execution of this command, the state of the redundant component associated with it should now be Active.
[local]host_name#
card reboot <slot#> -force
|
Step 2
|
Press Y to start the reboot of the card.
|
|
Step 3
|
Verify that the migration was successful by entering the show card table command at the prompt.
|
Check the entry in the Oper State column next to the line card that was just restored. Its state should be the state of that it was in before it was halted.
context <context_name>
context_name is the name of the context to which you wish to switch. The following prompt appears:
[context_name]host_name#
The ICMP ping command verifies the system’s ability to communicate with a remote node in the network by passing data packets between and measuring the response. This command is useful in verifying network routing and if a remote node is able to respond at the IP layer. The command has the following syntax:
ping <host_ip_address> [ count <num_packets> ] [ pattern <packet_pattern> ] [ size <octet_count> ] [ src { <src_host_name> | <src_host_ip_address> } ]
|
<host_ip_address>
|
Identifies the remote node to which is the target of the ping command.
host_ip_address specifies the remote node using its IP address entered in IPv4 dotted-decimal format.
|
|
count <num_packets>
|
num_packets must be within the range 1 through 10000. The default is 5.
|
|
pattern <packet_pattern>
|
packet_pattern must be specified in hexadecimal format with a value in the range hexadecimal 0x0000 through 0xFFFF.
packet_pattern must begin with a ‘0x’ followed by up to four hexadecimal digits.
|
|
size <octet_count>
|
octet_count must be a value in the range 40 through 18432. The default is 56.
|
|
src_host_name specifies the source node using the node’s logical host name which must be resolved via DNS lookup.
src_host_ip_address: specifies the source node using its IP address entered in IPv4 dotted-decimal format.
The default is the IP address of the interface through which the ping was issued.
|
|
•
|
If there is still no response, it is likely that the packets are getting discarded by a network device. Use the traceroute and show ip static-route commands discussed to further troubleshoot the issue (see below).
|
The traceroute command collects information on the route data will take to a specified host. This is a useful troubleshooting command that can be used to identify the source of significant packet delays or packet loss on the network. This command can also be used to identify bottle necks in the routing of data over the network.
traceroute { <host_name> | <host_ip_address> } [ count <packets> ] [ df ] [ maxttl <max_ttl> ] [ minttl <min_ttl> ] [ port <port_number> ] [ size <octet_count> ] [ src { <src_host_name> | <src_host_ip_address> } ] [ timeout <seconds> ]
|
<host_name>
|
host_name specifies the remote node using the node’s logical host name which must be resolved via DNS lookup.
|
|
<host_ip_address>
|
host_ip_address specifies the remote node using its IP address entered in IPv4 dotted-decimal format.
|
|
maxttl <max_ttl>
|
max_ttl must be specified as a value in the range of 1 through 255. It is an error if max_ttl is less than min_ttl, whether min_ttl is specified or defaulted.
|
|
minttl <min_ttl>
|
min_ttl must be specified as a value in the range of 1 through 255. It is an error if min_ttl is greater than max_ttl, whether max_ttl is specified or defaulted.
|
|
port <port_number>
|
Specifies a specific port to connect to where port_number must be a value in the range 1 through 65535. The default port is 33434.
|
|
Specifies the number of bytes each packet. octet_count must be a value in the range 40 through 32768. The default is 40.
|
|
|
src_host_name: specifies the remote node using the node’s logical host name which must be resolved via DNS lookup.
src_host_ip_address: specifies the remote node using its IP address entered in IPv4 dotted-decimal format.
The default is the IP address of the interface through which the ping was issued.
|
|
|
timeout <seconds>
|
seconds must be a value in the range 2 through 100. The default is 5.
|
|
<route_ip_address>
|
|
|
<route_gw_address>
|
show ip arp [ <arp_ip_address> ]
arp_ip_address specifies a specific network node for which to display ARP information. The address can be entered in IPv4 dotted-decimal or IPv6 colon-separated format. If this keyword is not specified, all entries within the context’s ARP table are displayed.
Important: Restarting the VPN Manager removes all interfaces from the kernel which in turn removes all ARP entries. However, the NPU still retains all of the ARP entries so that there is no traffic disruption. From a user point of view, show ip arp is broken since this command gathers information from the kernel and not the NPU.
Caution: The monitor tool may cause session processing delays and/or data loss. Therefore, it should be used only when troubleshooting.|
Step 1
|
Invoke the protocol monitor from the Exec mode by entering the monitor protocol command.
|
An output listing all the currently available protocols, each with an assigned number, is displayed.
|
Step 2
|
Choose the protocol that you wish to monitor by entering the associated number at the Select: prompt. A right arrow ( > ) appears next to the protocol you selected.
|
|
Step 3
|
Repeat step 2 as needed to choose multiple protocols.
|
|
Step 4
|
Press B to begin the protocol monitor.
|
|
Step 5
|
|
Step 7
|
Press the Enter key to refresh the screen and begin monitoring.
|
|
Step 1
|
To invoke the session-specific protocol monitor from the Exec mode enter the monitor subscriber command.
|
Important: Option Y for performing multi-call traces is only supported for use with the GGSN.|
Step 5
|
Repeat step 6 as needed to enable or disable multiple protocols.
|
|
Step 6
|
Press Enter to refresh the screen and begin monitoring.
|
The following displays a portion of a sample of the monitor’s output for a subscriber named user2@aaa. The default protocols were monitored.
Important: This tool must be executed from the context in which the DHCP server(s) are configured.Sample dhcp test dhcp-service Command Output
